state machine 케이스는 논외로.
데이터의 형, 종류, 범위, 조건이 복잡할 때, 나같은 노가다래머는 대략 3-4 가지의 선택에 직면한다.
디비 잘하는 사람들이 잘한다. 분리되는 어트리뷰트와 공통의 특성들을 잘 정의 한 후, 릴레이션 위주로 설계를 한다.
릴레이션이 잘 정의된 이후에는 새로운 조건을 추가해도 최초 설계의 범주에서 크게 벗어나지 않는다.
그러나 날C 코드에서는 이러한 릴레이션을 C로 표현한다는 것이 영 어렵다. 구조체 설계가 중요하다.
구조체는 포인터들로 연결해야 하며, 자료구조도 찾아봐야한다. ATL, STL 등등과 거리가 먼 이쪽 개발에서는 쥐약이다.
데이터형이 민주적으로 자유로우면 매번 헛갈리는 공용체를 써야 할 수도 있고, void * 로 전달하여 캐스팅을 하다가 버그가 나고, 데이터 얼라인으로 오와 열을 맞추다가 삐져나온 바이트가 속을 썩인다.
설렁설렁 노가다로 때우려다가 이 케이스로 돌아와야 할 때가 제일 슬프다. (처음부터 잘할 걸!)
대표적인 예를 들면 리눅스 등등의 네트웍 스택 sk_buff 쪽을 들 수가 있다. 디비쪽은 말할 것도 없거니와 전문 분야가 아니라 생략.
알바로 반도체공정 시뮬레이션과 관계된 과제를 한 적이 있다. 새로운 케이스를 정의하여 삽입/편집 가능하도록 구성하였다. 릴레이션에 따라 동작하는 엔진이 있었기에 엔진입장에서는 새로운 케이스가 들어오거나 말거나 기존 쿼리문과 키값의 연결성에 의존해서 하던 일을 할 뿐이다.
변수와 조건문이 기하급수 적으로 늘어난다. 인수인계 할 때 애로사항이 꽃핀다. 다만 케이스에 능통한 전문가 TF 라면 가장 빨리 짤 수도 있다.
전역변수가 늘어나고 switch case 문의 case 가 늘어나며 else if 가 저글링 처럼 보이기 시작한다. break 탈출 위치에서 괄호가 몇 겹이야 헷갈리기 시작한다.
원래의 루틴에 삽입 불가능 한 케이스들이 발생하기 시작한다. 결국 프로그래머는 땜빵 코드를 삽입하기 시작한다.
전역변수 플래그들이 등장한다. RTOS 와 인터럽트 분기가 개입해 있다면 각종 플래그들의 동기화 문제가 생기기 시작한다.
논리적 오류가 가장 발생하기 쉽다. 그러나 해당 잡에 능통하다면 가장 쉽게 디버깅할 수도 있다. 몇 줄의 케이스 추가로 추가 요구사항에 쉽게 대응가능하다.
코드를 즉각적으로 이래저래 바꿔보면서 test driven 하게 rapid prototyping 하기에도 좋다.
ctag 을 잘 쓰는 오리지널 프로개발자들이 이런 개발을 선택하면 에디터가 춤을 춘다. 뒤에서 구경하면 그 개발자가 마구 존경스러워진다. 쏘스 인사이트 같은 것을 쓰면 좋지만 나 같이 울트라에서 못 벗어나는 사람은 ctag 연동해도 잘 안 쓰게 되는 법. 써치 앤 파인드의 108계단 40...
조합형 한글을 추억하지 않을 수가 없다. 최초의 조합형 한글 코드 구현은 case 문으로 이루어졌다.
당시 폰트들은 초-중-종성에 있어서 10-4-4, 8-4-4, 4-1-1, 2-1-1 의 구성들을 가지고 있었다. "가"의 "ㄱ"과 "고"의 "ㄱ"을 구분해 내기 위해서 초창기 개발자들은 스위치를 돌렸다. 그리고 개발자들은 이것을 곧 배열에 의한 룩업으로 바꿨다.
배열 지향적인 설계는 여러모로 릴레이션 설계와 닯았다. 그러나 정방형의 배열안에 더미공간을 놔두고 마구 삽입하는 방식이다. 데이터 입력만 잘하면 에러도 없고, 속도는 가장 빠르다.
더욱이 조건문에서 처리하는 것이 별로 없다. 배열 인덱스의 최소/최대값 정도만 처리한다. 그러나 사소한 예외들에 대한 유연한 대응이 어렵다.
포인터 배열도 있으므로 잘짜는 프로그래머는 포인터를 깔아놓고 유연하게 쓸 수도 있다.
함수마저 배열로 포인터로 깔아놓으면 다양한 조건분기도 가능하다. 이 정도까지 오면 릴레이션형 설계라고 할 만도 하지만 이쪽이 더 원시적이고, 심플하다.
클래스도 (사실 나는 C++을 못한다) OS도 없는 환경에서 선택은 무엇인가? 나는 피곤하다.